home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
internet-drafts
/
draft-cameron-cmp-01.txt
< prev
next >
Wrap
Text File
|
1993-07-08
|
29KB
|
856 lines
Internet Draft P. Cameron
J. Bates
Xylogics, International Ltd.
April 1993
Connection Multiplexing Protocol (CMP)
Status of this Memo
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its
Areas, and its Working Groups. Note that other groups may also
distribute working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted
by other documents at any time. It is not appropriate to use
Internet Drafts as reference material or to cite them other than
as a "working draft" or "work in progress."
Please check the I-D abstract listing contained in each Internet
Draft directory to learn the current status of this or any other
Internet Draft.
It is intended that this document will be submitted to the IESG
for consideration as a standards document. Distribution of this
document is unlimited.
Abstract
One of the problems with terminal servers attached to a LAN is
the large number of small packets they can generate.
Frequently, most of these packets are destined for only one or
two hosts. CMP is a protocol which allows multiple Telnet and
Rlogin connections, between a server and a host, to share a
single TCP connection. With simple extensions this can be
expanded to include other TCP protocols.
Acknowledgments
This document is the work of many more contributors than just
the listed authors both here at Xylogics International and at
Xylogics Inc. Specifically Jim Barnes, Gary Malkin, James
Carlson, Dave Hirst and Miguel Sasson.
In addition, we would like to thank ICL Plc. in the U.K. and
Sweden for reviewing early versions of this proposal, and for
their assistance on early prototypes.
Cameron, Bates Expires: 1 Oct 93 [Page 1]
Internet Draft CMP April 1993
Table of Contents
1. Justification . . . . . . . . . . . . . . . . . . . . . 2
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Protocol Design . . . . . . . . . . . . . . . . . . . . 3
3.1 Header Format . . . . . . . . . . . . . . . . . . . . 3
3.2 Opening a Multiplexed Connection . . . . . . . . . . . 4
3.3 Opening a New Subconnection . . . . . . . . . . . . . 7
3.4 Sending Data . . . . . . . . . . . . . . . . . . . . . 7
3.5 Urgent Data . . . . . . . . . . . . . . . . . . . . . 8
3.6 Subconnection flow control . . . . . . . . . . . . . . 9
3.7 Closing a Subconnection . . . . . . . . . . . . . . . 10
3.8 Closing a Multiplexed Connection . . . . . . . . . . . 11
3.9 Standard Error Codes . . . . . . . . . . . . . . . . . 11
4. Multiplexed Messages . . . . . . . . . . . . . . . . . . 11
4.1 Construction . . . . . . . . . . . . . . . . . . . . . 11
4.2 Disassembly . . . . . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . 13
6. Authors' Addresses . . . . . . . . . . . . . . . . . . . 13
1. Justification
When network designers consider which protocols generate the
most load, they naturally tend to consider protocols which
transfer large blocks of data (e.g. FTP, NFS). What is often
not considered is the load generated by Telnet and Rlogin
because of the assumption that users type slowly and the packets
are very small. This is a grave underestimation on networks
which have many Telnet and Rlogin ports on multiple terminal
servers.
The problem stems from the fact that the work a host must do to
process a 1-byte packet is very nearly as much as the work it
must do to process a 1500-byte packet. That is, it is the
overhead of processing a packet which consumes a host's
resources, not the processing of the data.
If one assumes that most users connected to a terminal server
will be connecting to only a few hosts, then it should be
obvious that the network and host load could be greatly reduced
if traffic from multiple users, destined for the same host,
could be sent in the same packet.
2. Overview
CMP is designed to improve network utilization and reduce the
load on the hosts by multiplexing TCP connections which would
generate many small packets, onto a single TCP connection which
generates fewer larger packets.
Cameron, Bates Expires: 1 Oct 93 [Page 2]
Internet Draft CMP April 1993
The following terminology is used throughout this document.
Multiplexed Connection -
The actual TCP connection which exists between the server and
the client over which the subconnections exist.
Subconnection -
The "virtual TCP" connection between processes on the server
and client which exists over the Multiplexed Connection.
Message -
A single packet of data for a single subconnection plus its
header which is passed over the Multiplexed Connection.
Endpoint -
One of the two ends of a subconnection.
Multiplexed Message -
A packet which is sent over the Multiplexed Connection. It
is constructed from multiple CMP messages for multiple
subconnections.
3. Protocol Design and Subconnection Messages
CMP operates by prepending a 4 octet header onto each
subconnection's data, then appending that onto the end of the
packet which will be sent over the multiplexed connection. Upon
receiving a message, the individual subconnection datastreams
are demultiplexed and the information is handed up to the
application.
3.1 Header Format
The 4 octet header has the following general format:
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
+-----------+-------------------+
| TYPE | SIZE high |
+-----------+-------------------+
| SIZE low |
+-------------------------------+
| Dest ID (DID) high |
+-------------------------------+
| Dest ID (DID) low |
+-------------------------------+
Cameron, Bates Expires: 1 Oct 93 [Page 3]
Internet Draft CMP April 1993
The TYPE field has the following values:
0 - data (DATA)
1 - urgent data pointer (URG_DATA_PTR)
2 - open subconnection (OPEN)
3 - reply to OPEN message (OPEN_RPLY)
4 - close subconnection (CLOSE)
5 - reply to CLOSE message (CLOSE_RPLY)
6 - credit update (CREDIT)
Value 7 is reserved for future use.
For most commands, the SIZE field contains the number of octets
of 'data' following the header. For messages of type DATA this
will be the number of data octets, for other messages, this will
be the number of octets contained in subsidiary header fields.
For the CREDIT message, this field contains the number of bytes
of new credit available for the receiving end to use.
The DID is an arbitrary 16-bit number assigned by the receiving
end of a subconnection to identify the subconnection. The
receiver of a message uses the DID to uniquely identify a
subconnection. Note, this field is not used by the OPEN message
as no destination has been allocated.
3.2 Opening a Multiplexed Connection
The first time an application tries to open a TCP connection to
a remote host which has a CMP server, it first attempts to
create a Multiplexed Connection by opening the well known CMP
port, TBA. If that attempt succeeds (i.e. a TCP connection is
established), an OPEN message will then be sent by the clients
CMP process. If the Multiplexed Connection cannot be
established, the client should open a standard TCP connection
directly to the specified remote port.
The format of an OPEN message is:
Cameron, Bates Expires: 1 Oct 93 [Page 4]
Internet Draft CMP April 1993
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
+-----------+-------------------+
| 2 | 0 |
+-----------+-------------------+
| 6 |
+-------------------------------+
| 0 |
+-------------------------------+
| 0 |
+-------------------------------+
| Source ID (SID) high |
+-------------------------------+
| Source ID (SID) low |
+-------------------------------+
| Dest port high |
+-------------------------------+
| Dest port low |
+-------------------------------+
| Initial Credit high |
+-------------------------------+
| Initial Credit low |
+-------------------------------+
The SID is an arbitrary number, for example, it could be the
index into an internal table of connections. See discussion
below on the use of this field. The TYPE is 2, indicating the
opening of a new, in this case first, subconnection. The DID
field is not used as no destination has yet been allocated. The
Dest Port is the well known TCP port number for the application
(e.g. 23 for Telnet). The initial credit is the number of
octets of data that the endpoint opening the connection can
initially receive from the other endpoint.
The receiver of the open message will respond with an OPEN_RPLY
message. The format of an OPEN_RPLY message is:
Cameron, Bates Expires: 1 Oct 93 [Page 5]
Internet Draft CMP April 1993
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
+-----------+-------------------+
| 3 | 0 |
+-----------+-------------------+
| 6 |
+-------------------------------+
| Dest ID (DID) high |
+-------------------------------+
| Dest ID (DID) low |
+-------------------------------+
| Source ID (SID) high |
+-------------------------------+
| Source ID (SID) low |
+-------------------------------+
| Initial Credit high |
+-------------------------------+
| Initial Credit low |
+-------------------------------+
| Error code (ERR) high |
+-------------------------------+
| Error code (ERR) low |
+-------------------------------+
If the receiver cannot open the subconnection for any reason, it
will respond with an OPEN_RPLY message with a non-zero ERR field
(and a SID field of 0). If the receiver succeeds in opening the
subconnection, the ERR field of the OPEN_RPLY will contain zero.
See section 3.9 for a list of standard error codes. The initial
credit is the number of octets of data that the endpoint can
initially receive from the other endpoint.
It is important to note the use of the SID fields in both the
OPEN and OPEN_RPLY messages. This field is used to pass to the
other endpoint the value to be used in the DID field of all
subsequent messages sent back on this Subchannel. In
particular, the DID field of the OPEN_RPLY message should be set
from the SID field of the OPEN message.
Optionally having different DID fields in the two directions
allows the implementor of each end much greater freedom in the
use of the DID field, hence the opportunity to make the
implementation more efficient. For example, if the endpoint has
a table of information about each open subconnection, then the
DID can be the index into this table. This is a much more
efficient implementation than scanning the table and much easier
to implement than a hash table lookup.
Cameron, Bates Expires: 1 Oct 93 [Page 6]
Internet Draft CMP April 1993
Thus, the sequence of messages and their SIDs and DIDs could be:
Endpoint 1 Endpoint 2
---------- ----------
TYPE=OPEN
--------------->
DID=0
SID=D1
TYPE=OPEN_RPLY
<----------------
DID=D1
SID=D2
TYPE=DATA
--------------->
DID=D2
TYPE=DATA
<----------------
DID=D1
3.3 Opening a New Subconnection
When a user on a client attempts to open a TCP connection to a
host server for which a Multiplexed Connection exists, the
client simply adds that TCP connection as a new subconnection by
sending an OPEN message and receiving back an OPEN_RPLY message
(see section 3.2).
Once a Multiplexed Connection has been established, either side
may initiate an OPEN request.
3.4 Sending Data
Subconnection data is preceded by the following header:
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
+-----------+-------------------+
| 0 | Length high |
+-----------+-------------------+
| Length low |
+-------------------------------+
| Dest ID (DID) high |
+-------------------------------+
| Dest ID (DID) low |
+-------------------------------+
The DID is the identification for the subconnection. The TYPE
is 0. The SIZE field specifies the length of the data
immediately following the header; it does not include the length
Cameron, Bates Expires: 1 Oct 93 [Page 7]
Internet Draft CMP April 1993
of the header.
3.5 Urgent Data
TCP requires the ability to send individual octets marked as
"urgent" data. When an application requests this, it expects
that the remote end of the communications stream is notified as
soon as possible that urgent data is pending, and it expects
that the remote end will be able to mark this octet and deliver
it either in-line or as out-of-band data. This feature is
implemented over a Multiplexed Connection using an URG_DATA_PTR
message. The format of the urgent data pointer message is:
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
+-----------+-------------------+
| 1 | 0 |
+-----------+-------------------+
| 2 |
+-------------------------------+
| Dest ID (DID) high |
+-------------------------------+
| Dest ID (DID) low |
+-------------------------------+
| Urg Data Ptr (URG) high |
+-------------------------------+
| Urg Data Ptr (URG) low |
+-------------------------------+
The DID is the identification for the subconnection. The TYPE
is 1. The URG field indicates the number of bytes of type DATA
(for this subconnection) which follow this URG_DATA_PTR message
upto and including the byte of urgent data being sent.
Normally the urgent data byte will be queued behind any other
data waiting to be transmitted on this subconnection (see
section 4.1). An URG_DATA_PTR message will be sent immediately,
indicating the number of data bytes waiting to be transmitted
upto and including the byte of urgent data on this
subconnection. This enables the receiver to be made aware that
there is urgent data queued even if there is no available
credit.
If an application sends another octet of urgent data before a
previous one has been read, the receiver is expected to indicate
to its applications that there is urgent data present until the
last known piece of urgent data has been received by the user.
Some implementations may choose to expedite the transmission of
data preceding and including the urgent data.
Cameron, Bates Expires: 1 Oct 93 [Page 8]
Internet Draft CMP April 1993
3.6 Subconnection Flow Control
CMP supports flow control on a subconnection basis to ensure
that a single subconnection can not tie up vast amounts of
resources to the detriment of the other subconnections. Flow
control in CMP is accomplished by use of a credit/debit system.
Each endpoint knows the maximum number of octets of data
(contained in messages of type DATA) that the other endpoint is
able to receive, and may not send more than this number, it can
of course send less. After sending a DATA message, the endpoint
should decrease its outstanding credit by the number of octets
just sent. Once the other endpoint has processed the data, it
will send back CREDIT messages to tell the sending endpoint how
many more octets of data it can now receive. Note, an endpoint
can send CREDIT messages when it wishes to, there are no
constraints on the timing, and it may not grant back to the
other endpoint all the credit it initially had (or it may grant
more). The format of the CREDIT message is:
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
+-----------+-------------------+
| 6 | Extra credit high |
+-----------+-------------------+
| Extra credit low |
+-------------------------------+
| Dest ID (DID) high |
+-------------------------------+
| Dest ID (DID) low |
+-------------------------------+
The DID is the identification for the subconnection. The TYPE
is 6.
The extra credit field is the number of octets of data space
that have become available at the endpoint sending the message.
This value should be added to the credit value currently held.
After an OPEN message, the credit available is given in the
initial credit field of the OPEN or OPEN_RPLY message. It is
allowable to subsequently increase the total amount of credit
available, but it should never be reduced below the initial
value. This allows the sender to decide whether to send part of
a data block or to wait for further credit updates and to then
send the whole data block.
It is suggested that credit update messages are sent on the back
of an outgoing multiplexed message. This allows a single credit
update message to reflect all of the credit that has become
available within a delay timer period. Thus reducing the risk of
Silly Window Syndrome.
Only messages of type DATA are controlled by the credit/debit
system, all other messages can be sent at any time.
Cameron, Bates Expires: 1 Oct 93 [Page 9]
Internet Draft CMP April 1993
3.7 Closing a Subconnection
When one side of the subconnection wishes to close, it sends a
CLOSE message. This indicates that there is no more data to be
sent. After sending this message an endpoint MUST NOT send any
more data. The side which receives the Close Request continues
to send data until there is no more data to be sent, at which
time it sends a CLOSE_RPLY message. A CLOSE message has the
following format:
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
+-----------+-------------------+
| 4 | 0 |
+-----------+-------------------+
| 1 |
+-------------------------------+
| Dest ID (DID) high |
+-------------------------------+
| Dest ID (DID) low |
+-------------------------------+
| Close type |
+-------------------------------+
The DID is the identification for the subconnection. The TYPE
is 4.
The close type field contains the type of close to be done:
0x00 Standard close
0x01 Reset.
A standard CLOSE will allow all data currently in transit to be
sent, but a reset CLOSE will cause this data to be flushed.
The CLOSE_RPLY message has the following format:
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
+-----------+-------------------+
| 5 | 0 |
+-----------+-------------------+
| 2 |
+-------------------------------+
| Dest ID (DID) high |
+-------------------------------+
| Dest ID (DID) low |
+-------------------------------+
| Error code (ERR) high |
+-------------------------------+
| Error code (ERR) low |
+-------------------------------+
The DID is the identification for the subconnection. The TYPE
is 5. The ERR field is used to return an error code. A value of
Cameron, Bates Expires: 1 Oct 93 [Page 10]
Internet Draft CMP April 1993
0 is used where the Close was successful, a non-zero value
indicates an error. See section 3.9 for a list of error codes.
A subconnection is not closed until one endpoint issues a CLOSE
Request, and the other endpoint responds with a CLOSE_RPLY
message. Note, the subconnection is closed on receipt of the
CLOSE_RPLY message, regardless of the value of the ERR field.
Where the close type is 'reset' the receiver should send the
CLOSE_RPLY message immediately, it should not wait for data to
flush.
If an endpoint sends a normal CLOSE message, and does not
receive a CLOSE_RPLY message it is permissible to send a second
CLOSE message with a 'close type' of 'reset'. In this situation
it must be possible to cope with receiving either 1 or 2
CLOSE_RPLY messages.
3.8 Closing a Multiplexed Connection
When the last subconnection on a Multiplexed Connection has
closed, the Multiplexed Connection should also be closed, as any
TCP connection would be.
3.9 Standard Error Codes
The standard error codes to be used in the ERR field of the
OPEN_RPLY and CLOSE_RPLY messages are:
ESUCCESS 0 Command completed successfully
ENXIO 5 No such device or address
ENOMEM 8 Not enough core
EACCES 9 Permission denied
EBUSY 10 Device busy
ENODEV 11 No such device
ESECURITY 54 Security fault
EMJOB 57 Job limit exceeded
ESECURITYERR 59 Security server is unreachable
Any other non-zero values may also be used to signify an error
condition.
4. Multiplexed Messages
A Multiplexed Message is the packet which is sent over the
Multiplexed Connection. It is constructed from multiple CMP
messages for multiple subconnections.
4.1 Multiplexed Message Construction
When an application running over a subconnection sends a packet,
the CMP prepends that packet with a header to create a CMP
message, then appends the message to the Multiplexed Message
Cameron, Bates Expires: 1 Oct 93 [Page 11]
Internet Draft CMP April 1993
under construction.
When the first message to be transmitted is placed into the
Multiplexed Message under construction, a timer is started.
When the timer expires, all outstanding message are placed into
the Multiplexed Message and it is transmitted. This ensures that
all messages constructed before the timer expires are sent in a
single Multiplexed Message. If during construction of the
Multiplexed Message the buffer holding the packet fills, the
Multiplexed Message is transmitted immediately.
The delay time should be user configurable; a reasonable time is
20 to 30 milliseconds. The time period wants to be large enough
to give a reasonable probability of sending multiple packets but
not so large that the echo response time becomes a problem.
This suggests that the upper limit for the timer is probably
1/10th second. As the cost of using timeouts on many systems is
quite large it is recommended that a single timer is used and
that all connections are serviced on each expiry period. In
particular where a large timeout period is specified it is
probably wise to turn off the Nagle algorithm within TCP to stop
echo responses becoming unacceptable if there is light traffic.
Additionally, configuration options may limit the number of
included data packets or the maximum size of the Multiplexed
Message before it is transmitted.
If urgent data arrives for a subconnection, this is added to the
Multiplexed Message and an URG_DATA_PTR message is transmitted
immediately (see section 3.5).
4.2 Multiplexed Message Disassembly
When a Multiplexed Message is received, the CMP immediately
accepts it from TCP. It is important to try and keep the TCP
connection drained so that the TCP window remains open. In the
event of TCP falling behind then all subconnections are delayed.
The CMP driver should honor TCP's flow control and ensure that
no data is lost or placed out of sequence.
Each message in the Multiplexed Message (i.e. data message or
control message) is processed in turn. The data contained in
DATA messages is sent to the applications as though they were
directly interfaced to TCP. If only part of a DATA message is
received within a TCP packet it is implementation dependent as
to whether the partial block is passed on to the application
before the rest of the data is received. If an URG_DATA_PTR
message is received the presence of urgent data will be
indicated to the applications in the same manner that TCP uses.
All other message types are dealt with by the CMP interface
layer.
In the event of a protocol error then all subconnections should
be told to hangup and the TCP connection should be shutdown.
Cameron, Bates Expires: 1 Oct 93 [Page 12]
Internet Draft CMP April 1993
5. Security Considerations
If a site's security is instituted on an host-to-host basis, CMP
does not introduce a security problem. If security exists on a
per connection basis, CMP would need to provide a mechanism for
allowing or disallowing certain users access to a multiplexed
connection. Such a mechanism could be added, but is beyond the
scope of this document.
6. Authors' Addresses
Peter Cameron and Julian Bates
Xylogics International Ltd.
Featherstone Road
Wolverton Mill
Milton Keynes
MK12 5RD
UK
Phone: +44 908 222112
Fax: +44 908 222115
Email: cmp-id@xylint.co.uk
Cameron, Bates Expires: 1 Oct 93 [Page 13]
